S-&b 


Report No. CDOT-DTD-R-93-5 


Expert System for 
Retaining Wall Selection 


PHASE I 


Teresa M. Adams 

Assistant Professor 

University of Wisconsin—Madison 
Madison, Wisconsin 53706 


- Final Report 


June 17, 1992 


Prepared im cooperation with the 

U.S. Department of Transportation 
Federal Highway Administration 

and 

Colorado Department of Transportation 
4201 E. Arkansas Ave. 

Denver, Co. 80222 


Technics! Report Documentation Page 
1. Repers Ne, 2. Government Accensian Ne. 3. Recsacenr's Caralag Ne. 
CDOT-—DTD-R-93-5 


4. Title end Subtitie S$. Repert Care 


Expert System for Retaining Wall Selection 


4. Porterming Organizenen Code 


File 74.02 1571P 


8. Porterming Orgenization Report Ne. 


7, Aurned a) 
Teresa M. Adams #GT-92-1-TMA CDOT-—DTD-—R-93-5 
9. Pertannung Organisation Neme end Address 10. Work Unit Ma. (TRAIS) 


Department of Civil 1& Environmental Engineering 
University of Wisconsin-Madison 


TI. . Canevecr or Geant Na. 
Madison, Wisconsin 53706 | 


13. Type of Repert and P eried Covered 


ive Spennacing Agency Neme ond Address 


Colorade Department of Transportation Final Report 


4201 E. Arkansas Avenue 
Denver, CO 80222 


14, Spenaaring Agency Code 


TS. Supplementary Neres 
Prepared in Cooperation with the U. S. Department of Transportation 
Federal Highway Administration 


34. Abstract 

The Bridge Branch of the Colorado Department of Transportation (CDOT) has 
organized a formal decision process for retaining wall’ selection 
(CDOT 199la; CDOT 1991b). The selection process facilitates implementation of new 
technologies by encouraging Bridge Branch designers and consultants to consider a 
range of options when selecting retaining wall alternatives. The formalized 
retaining wall selection process puts the CDOT into a national leadership role. 
What was needed was a computerized implementation of the decision process that would 
reduce the time required to perform the retaining wall selection process; enforce 
consistency in decisions made by designers and consultants; and provide a mechanism 
for the CDOT to encode standard practices and minimum performance criteria within the 
decision process. The CDOT retaining wall selection process falls into a general 
pattern of organization that can be automated using currently available expert system 
technology. 


Seed money (PHASE 1) was provided by the Colorado Department of Transportation 
to develop a conceptual system and design description that implements the CDOT 
selection process. This investigation has served to evaluate the feasibility and 
level of difficulty for full system development. The study included considerations 
for dissemination and program maintenance for a system that runs on IBM-compatible 
micro-computers. The cost of disseminating run-time versions of the full system were 
to be minimized. This report comprises the results of the pilot study. 


17. Key Weeds 18. Olsrribution Stetwnent 


Retaining wall selection, No Restrictions: This report is 
computerized implementation, available to the public through the 
decision process National Information Service, 


Springfield, Virginia 22161 


19. Security Cleasif, (of this report! 2. Security Clasaif. (af this pege) Zle Ne. af Pages 
Unclassified Unclassified 20 


Form DOT F 1700.7 (8-72) ; Rapraduction of completed page eutherized 


li 


Expert System for Retaining Wall Selection 
PHASE I 


FINAL PROJECT REPORT 
Submitted to the 
Colorado Department of Transportation 
Robert Barrett, Geotechnical Research Coordinator 
Richard Griffin Jr., Research Engineer 


by 
Dr. Teresa M. Adams, Principal Investigator 
Assistant Professor 
Department of Civil and Environmental Engineering 
University of Wisconsin-Madison 
(608) 262-5318 
adams@engr.wisc.edu 


June 17, 1992 


PROJECT SUMMARY 


The Bridge Branch of the Colorado Department of Transportation (CDOT) has organized a 
formal decision process for retaining wall selection (CDOT 1991a; CDOT 1991b). The selection 
process facilitates implementation of new technologies by encouraging Bridge Branch designers 
and consultants to consider a range of options when selecting retaining wall alternatives. The 
formalized retaining wall selection process puts the CDOT into a national leadership role. What 
is needed is a computerized implementation of the decision process that will reduce the time 
required to perform the retaining wall selection process; enforce consistency in decisions made by 
designers and consultants; and provide a mechanism for the CDOT to encode standard practices 
and minimum performance criteria within the decision process. The CDOT retaining wall selection 
process falls into a general pattern of organization that can be automated using currently available 
expert system technology. 

Seed money (PHASE 1) was provided by the Colorado Department of Transportation to 
develop a conceptual system and design description that implements the CDOT selection process. 
This investigation has served to evaluate the feasibility and level of difficulty for full system 
development. The study included considerations for dissemination and program maintenance 
for a system that runs on IBM-compatible micro-computers. The cost of disseminating run-time 


versions of the full system were to be minimized. This report comprises the results of pilot study. 


RESEARCH OBJECTIVES 


This report describes the results of the first phase of a mult-phase project for for developing a 

. comprehensive system for retaining wall selection, design and cost estimation. This phase (PHASE 
I) focused on the conceptual model, knowledge base organization and inferencing for coding a 
system that allows designers and consultants to interactively assemble retaining wall project data 
for evaluating the measurement indicator values of the spatial, behavior, and economic factors 
shown on the CDOT Work Sheets for Earth Retaining Wall Type Selection (CDOT 1991b). The 
system will eliminate wall types that are infeasible due to spatial, behavior and economic factors. 
Weighted scores for the feasible wall types will be computed and the wall types will be rank 


ordered. The objectives of the system are: 


1. To implement a representational framework for computerized retaining wall selection that 


. 1s compatible with the CDOT decision process. 
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2. To enable designers and consultants to interactively assemble retaining wall selection 


decision criteria. 
3. To codify of CDOT retaining wall selection process in Memos 5-4 and 5-5. 


The system described in this report can be used to develop a retaining wall selection system 
that encodes the CDOT retaining wall selection process. The resulting system is expected to assist 
rather than replace a knowledgable, experienced retaining wall design engineer. This report can 
be used as the basis for developing the initial framework of a full system that can subsequently be 
expanded and maintained by CDOT Bridge Branch engineers. The full system will: 


e Assist the engineer to eliminate infeasible, unsuitable, and undesirable walls based on 


spatial, behavioral and economic constraints. 
e Assist in computing the evaluation score for each feasible wall alternative. 


e Provide an output report of the selection process that can be included with other project 


design documents. 


HISTORICAL PERSPECTIVE AND INTRINSIC MERIT 


The last decade has seen enormous interest in the application of expert systems to geotechnical 
engineering and highway design problems. Table 1 contains a listing of a number of prototype 
systems that have been described in the literature. 

Researchers have shown that expert systems can be applied to retaining wall problems. 

. Retaining wall selection has been the subject of previous expert system prototypes (Arockiasamy 
et al 1991; Hutchinson 1985). In addition expert system technology has been applied to retaining 
wall management (Chahine 1986), failure diagnosis (Adams et al 1989; Adams et al 1988), and 
rehabilitation design (Adams et al 1991; Adams et al 1990; Ciarico et al 1989). In each case, 
researchers cite the potential for retaining wall construction cost savings. 

The barrier to full completion of previous retaining wall expert systems has been the need 
for additional knowledge sources and high-level commitment for system completion. The CDOT 
has compiled retaining wall selection knowledge from in-house sources. In addition, there is 
high-level commitment from the Bridge Branch to support the development of a computerized 
framework. It is expected that the experience gained from previous projects will benefit the CDOT. 
Thus, the proposed project will begin where similar projects have ended. 
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Table 1: Geotechnical Expert Systems 
System Development 
Name Description Environment 
i ESPGIS Selection of ground improvement methods (Motamed | VP Expert 
et al 1991) 


(1991; Geological site characterization (Halim et al 1991) 


—+— Selection of geosynthetic ground improvement (Ma- | Rulemaster 
her and Williams 1991) 


1991 f Selection of retaining walls (Arockiasamy et al 1991) | M.1 Rulemaster 


1991 Selection of earth retaining structures (Oliphant and | FRIL, Prolog 
Blockley 1991) 


1991 Estimation of soil strength parameters (Gillette 1991) | PC + 
mick et al 1991) 
and Santamarina 1989) 
taining structures (Adams et al 1990) 
strategies (Ho et al 1989) 


1989 | SITECLASS | Site classification (Wong et al 1989) SUCAM 


1989 | SOIL Soil classification (Madhavan et al 1989) CBC X-pert 


1988 | FOOTER Design synthesis for building foundation (Adams et al | EDESYN 
1989) 


1988 | EXSEL Diagnosis of seepage in dams (Asgian et al 1988) ARITY PROLOG 


-| 1988 | GEOTOX Hazardous waste management (Mikroudis and Fang | Ada-Prolog | 
1988) 


1986 Daisy 
determination (Adams et al 1989) 
walls (Chahine 1986) 


1985 | RETWALL | Selection of earth retaining walls (Hutchinson 1985) | BUILD 


1985 | SITECHAR | Site characterization (Rehak 1985) 


1985 | CONE Interpretation of cone penetrometer test data re- | Lisp 
sults (Mullarkey et al 1985) 
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Figure 1: Architecture of the CDOT Wall Selection System 


FRAMEWORK FOR AN EXPERT SYSTEM FOR RETAINING WALL SELECTION 


The conceptual framework for an expert system for selecting retaining wall alternatives is 
shown in Figure 1. The conceptual framework for the CDOT retaining wall selection system 
including consideration of the user interface, explanation facilities, and reasoning with uncertainty. 
The system is comprised of four main modules: Input, Selection, Ranking and Output. The 
system selects feasible wall types by process of elimination then scores and ranks feasible retaining 


- alternatives. The functional description of each module comprise the following paragraphs. 


Input Module 
In the Input Module, the user inputs problem-specific constraints as per Memo 5-4 of the 
CDOT Bridge Branch. In this module, the user will also input general information such as wall 
height and length. Constraints are organized into five categories: 
1. Functional Constraints are related to the purpose of the retaining structure. 
e Roadway (Front/Back-top) 
e Grade separation 


e Landscaping 


e Noise control 
e Ramp or Underpass 
e Temporary Shoring of Excavation 
e Stability of Steep Side Slope 
e Flood Control 
e Bridge Abutment 
2. Spatial Constraints are related to site accessibility and space limitations. 
e Material and Equipment Access 
e Material and Equipment Storage 
e Maintaining Existing Traffic 
e Proposed Profile (Cut/Fill) 
Working Space in Front of Wall 
e Excavation Space Behind Wall 
3. Behavioral Constraints are related to the structural and geotechnical performance of the 


system. 
e Quality of Fill Material 
e Ground Water Table 
e Bearing Capacity 
4. Economic Considerations are related to the cost of wall construction. 
e Noise/Vibration Control 
e Construction Time 
5. Other Constraints include additional spatial, behavioral, environmental, and economic 
constraints that are listed in Memo 5-4. These constraints are reported at the end of the 
consultation. 
e Other Spatial Constraints: Right of Way; Geological Boundaries; Temporary and 
Permanent Easement; Minimal Site Disturbance; Underground easement. 
e Other Behavioral Constraints: Wall Design Life. 
e Environmental Constraints: Ecological Impacts on Wetlands; Stream Encroachment; 
Fish/Wildlife Habitation or Migration Routes; Aesthetic Constraints; Urban Versus 
Rural; Design Policy of Scenic Routes; Anti-graffiti Wall Facing; Avoiding Valley 
Effect of Long/High Wall. 


e Other Economic Factors: “Buy Colorado” Impact; Temporary Versus Permanent Wall 
and Future Widening; Negotiated Bidding and Design/Build on Non-Standard Projects; 
Complexity of Project; Experience and Equipment of Local Contractors; Proprietary 
Product and Quality Assurance. 

Input constraint data can be stored as “facts” in working memory of the system. The user can 
access the explanation facility to learn WHY a particular constraint is requested; that is how the 
constraint will be used to eliminate wall types. 


Selection Module 

The purpose of the Selection Module is to eliminate infeasible wall type. Wall types are 
eliminated using the Function, Spatial, Behavioral, and Economic Constraints gathered in the 
Input Module. This module has three phases. 


1. Inthe first phase, obviously infeasible wall types are eliminated without further consultation. 
A knowledge base of the infeasible relationship between constraints and wall types will be 
prepared for this phase. The knowledge base can be visualized in tabular form. A meta 
rule can operate to eliminate infeasible wall types by matching input constraints with the 
relationship in the knowledge base table. Elimination of obviously infeasible wall types 
based on a combination of constraints is also possible (Adams 1992). 


2. In the second phase, the number of the feasible wall types can be further reduced through 
consultation according to problem-specific constraints. The knowledge base for this phase 
should contain zero, one, or more rules for each combination of constraint and wall type. 
Based on the user’s response, each rule can potentially eliminate a wall type. For example, 
a rule to eliminate modular walls due to inadequate storage space for materials may be as 


follows. 


(defrule STORAGE-SPACE 
?ptr<- (WALL (wall_type modular) (prospect feasible) ) 
(SITE (constraint_type spatial) 
(constraints $? storage $? ))} 
=> 
(printout t crlf “Is storage space inadequate for a modular wall[y/n]: ") 
(bind ?ans (read) ) 
(if (eq ?ans ylYlyes| YES) 
then (modify ?ptr (prospect infeasible) )) 
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3. In the third phase, site-specific (or allowable) conditions are logically compared to wall- 
specific (or required) conditions to eliminate infeasible wall types (see Worksheet Memo 
5-5). The value of site-specific and wall-specific conditions are represented in terms of 
the measurement factors used in Memo 5-5. Table 2 contains the hierarchy of the value 
of measurement factors. In this module, the user inputs all site-specific conditions once. 
Wall-specific conditions are input as the comparison process progresses. A wall type is 
found infeasible and eliminated when a single wall-specific (required) condition cannot be 
satisfied by a site-specific (allowable) condition. For example, below is a rule for eliminating 
a wall type by logically comparing the measurement factor for the required working space 


of the wall with the allowable working space at the site. 


(defrule ALLOWABLE_SPACE 

?ptr <- (WALL (space ?required) (prospect feasible) ) 
(SITE (space ?allowable) ) 
(test ( < Pallowable ?required)) 

=> 


(modify ?ptr (prospect infeasible) )) 


The Selection Module should include WHAT-IF explanation to allow the user to revise wall- 
specific conditions. At the end of this module, a set of feasible wall types are passed to the Ranking 
Module. 


Ranking Module 
Feasible retaining wall alternatives are scored and ranked according to the Evaluation Factors 
‘in Memo 5-5 and listed in Table 3. The steps of the ranking process are listed below. In the ranking 
process, weight values are assigned by the user. It is envisioned that some rating values may be 


generated by the expert system from the measurement indicators in the Worksheet of Memo 5-5. 


1. Weight value, W;, is assigned by the user to each evaluation factor. 


e W; represents the importance of the :** evaluation factor in the overall project decision. 


e Each W; is independent of any wall alternative. 
8 
> W; = 100 
i=] 
2. A set of rating values, ;, is generated for each kt wall alternative. 
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Table 2: Hierarchy of Measurement Factor Values 


Spatial Factors 

Excavation Behind Wall 
Working Space of Wall 

Front Face Battering 
Behavioral Factors 

Sensitivity of Differential Settlement 
Quality of Backfill Material 
Water Table Presence 

Active Earth Pressure Condition 
Construction Dependent Loads 
Economic Factors 

Noise/Water Pollution 

Quantity of Backfill Material 
Fill Compaction and Control 
Relative Construction Time 
Cost of Maintenance 
Availability of Standard Design 
Labor Usage 

Facing as an Extra Cost 

System Durability Problem 


Table 3: Evaluation Factors and Subscripts. Used to Rank Feasible Retaining Walls. 
[+ Evaluation Factor 
Constructibility 
Maintenance 
Schedule 
Aesthetics 


Environment 
Durability 
Standard Designs 
Cost 


e Each R;, indicates how well wall type & satisfies evaluation factor 7. 
e Ratings can range from 1 to 5. 


3. Score, S;, is computed for each k** wall type. 


a 
Se =o RW; 


t=1 


4. Alternative with the highest score is the “default design.” 


Output Module 

All project-specific input is summarized in the Output Module. Eliminated wall types are 
summarized with the first unsatisfied constraint that eliminated the wall type. Scores and ranking 
of alternative wall types are reported. Other constraints that are collected in the Input Module but 
not considered by the system are summarized. These constraints may influence the final decision. 
WHAT-IF explanation will allow the user to change certain values of input and check the effect of 


those values on the system results. 


EXPERT SYSTEM SHELL SELECTION 


An expert system can be developed using an AI (Artificial Intelligence) language or an expert 
system shell. When selecting a shell or language, one must consider the trade-off of ease of use for 
power and flexibility. For an ill-structured problem, one may select an AI language or a low level 
shell. For a well-structured problem, one may find a shell that provides pre-programmed features 
and knowledge representation that are needed. Table 4 contains a comparison of AI languages and 
"shells (Ferrada and Holmes 1990). 

Features of expert system shells can be categorized into groups of built-in tools that aim to sim- 
plify the development process by providing for knowledge acquisition, knowledge representation 
and user interface (Simmons et al 1991). Knowledge Acquisition (KA) is an expensive, people 
intensive activity where knowledge is elicited by a domain expert. KA is typically the bottleneck 
in building an expert system. There have been efforts to build KA tools, but they have not evolved 
into commercial products. 

Table 5 contains a comparison of the various features of commercial expert system shells. 
Most shells utilize facts and rules as primitives for constructing the knowledge base and knowledge 


representation. In some tools primitives may be combined, suck. as rules into modules or facts 


10 


Table 4: Differences Between AI Languages and Shells 


AI Language 


Considerable amount of code has to be 
written. 


System can be programmed to approach the 
solution to a problem from different perspec- 
tives. 


May require considerable amount of time to 
develop components of the application from 
‘scratch’. 


Used when certain features are not provided 
by a shell OR to reduce overhead when a shell 
has many features that are not utilized in a 
particular application. 


Often requires the participation of a computer 
programmer. 


Examples : LISP, PROLOG, SMALLTALK, 
C++, OBJECTIVE-C 
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Shell 


Provides substantial programming code in- 
cluding a tested, debugged and maintained 
INFERENCE ENGINE. 


Applies the same rules of inference to a 
variety of problems (ie.. PROGRAMMED 
HEURISTICS). 


Can shorten development time by providing 
pre-programmed components. 


Can be used by technical personnel not having 
extensive programming capabilities. 


Examples: CLIPS, VP-EXPERT, KEE, NEX- 
PERT 


into frames with inheritance. All shells include pattern matching and inference mechanisms, 
however, the flexibility of the pattern matching and the possibilities for inferencing vary among 
shells. Some shell features for knowledge representation include the following. Depending on the 
shell, input data or conclusions can be TRUE, FALSE, UNKNOWN, POSSIBLE, UNLIKELY. 
UNDECIDABLE etc. Flexibility of truth values are used for assessing the degree to which data 
is known to be correct. Reasoning with uncertainty allows the developer to represent plausibility 
by attaching certainty to the logic in the rules. Schemes have been developed for reasoning 
with uncertain and imprecise knowledge. They include Bayesian techniques, confidence factors, 
Dempster-Shafer evidential reasoning and fuzzy logic. 

Flexibility in the inferencing allows the developer to modify the basic control of the system; 
that is the order in which rules are fired. Shells typically provide one or both or the two fundamental 
control strategies: Forward and Backward chaining. Message passing and Demons are the control 
mechanisms in object oriented programming. 

Temporality is a feature that is necessary when elements of the problem must be associated 
with specific points in time or time intervals. Real-time systems make use of this property. In 
temporal system, data and conclusions possess distinct truth values at different times. 

Procedural knowledge can be represented using conventional programming languages such 
as Fortran and C. Shells that only use non-procedural technique are considerably limited in their 
usefulness for engineering applications. Most shells provide some type of interface to conventional 
programming languages, although the efficiency and ease of use of these interfaces varies widely. 
Some shell provide a simple Pascal or BASIC-like language so that simple algorithms may be 
incorporated into rules without the need for external languages. 

Shells vary widely in their user friendliness to the developer and to the end user. All shells 
provide some mechanisms for entering data about the problem. Input options include automatic 
menus, line input, multiple responses and uncertain responses. Explanation facilities are useful 
to the developer in debugging the systems as well as to the end user. Explanation falls into three 
basic types: HOW, WHY, and WHAT-IF. Most shells provide the HOW explanation of how the 
system arrived at a conclusion through rule tracing or audit trails of the line of reasoning. The 
WHY explanation indicates why certain input is needed in terms of how it will be used in certain 
rules. The WHAT-IF explanation allows the user to generate alternative problem solutions by 
changing input data. 

All shells that provide external hooks to procedural languages can incorporate graphics into 
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a final application. Some shells provide a feature for graphical representations of the knowledge 
base in the form of a tree or network. A shell may also include features for active images and 
simulation. 

Some shells provide specialized links to databases, spreadsheets, CAD software, real-time data 
acquisition tools. Most shells provide links to external procedures and text files. Some shells are 


available on several hardware and operating system platforms. 


RECOMMENDATIONS 


This report describes the framework for an expert system for retaining wall selection that follows 
the problem solving methodology described in the CDOT Memos 5-4 and 5-5. Development and 
implementation of a system that follows this framework will: 

e Reduce the time required to perform retaining wall selection; 

e Enable consistency and consideration of multiple retaining wall alternatives in decision- 

making by designers and consultants; and 

e Provide a mechanism for the CDOT to encode standard practices and minimum performance 

criteria. 

The recommended criteria for selecting a development shell for the CDOT project are 
summarized below. The criteria were established as a result of meetings with Colorado Bridge 
Section Engineers and formulating the functional specification of the final system. 

e Knowledge Representation—system is expected to be primarily rule-based 

e Inference Mechanism—forward chaining 

e Explanation—why, what-if, how 

e Development Toolbox—Trade-of features for flexibility and power for ease of use. We want 

a shell that allows us to develop a system that is patterned after the CDOT memos. 

e External Hooks—algebraic programming, database systems 

e Cost for Dissemination-distribution cost of runtime copies of the system should be mini- 

mized. 

The shell recommended for the Colorado project is CLIPS version 5.1 (Giarratano 1991). ‘C’ 
Language Integrated Production Systems (CLIPS) is a knowledge-based shell initially developed at 
Johnson Space Center in 1984. CLIPS accommodates storage of domain knowledge; provides an 
inference engine that fires on rule bases; and supports CLIPS Object-Oriented Language (COOL). 
Run time (compiled) copies of the final system may be distributed without licensing restrictions. 
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Table 5: Comparison of Commercial ES Shells (Simmons et al 1991) 


Knowledge Inference 


Representation 


Explanation 


Name Mechanisms | Facilities Uncertainty 


Development External 
Interface ; Hooks 


VP Expert | rules; booleans (V, A); 


modules 


CLIPS 5.1 


ECLIPSE ath va TTF 
|KES | rules; demons; frames 
le 


KES 
rules; booleans (V, A, —); 


frames; inheritance; mod- 
ules, messages, demons 
Rule Master 


Exsys 


hy 
rules; booleans (V, A, =); | F, B how truth values—T/F 
modules, objects 

ow 


how, what-if, 
why 


B 
F,B,H 


° 
how, what-if 
,B,H 


F 
F 


rules; booleans (V, —) truth values—T/F; 


CF range—no limit 


tules; booleans (V, A, 7); 
demons 


truth values—T/F ?; 
CF (0 to 100) 


booleans (V); inheritance; 
frames; rules; demons 

rules; booleans (V, A, —); 
frames; inheritance; mod- 
ules; messages; demons 


truth values—T/F; 
CF (-100 to 100) 


truth values—T/F ? 


how, why 


NEXPERT how, what-if, 
why, 


graphics 


F, B,H how, what-if, automatic menus; 
w multiple responses 
rules; booleans (V, A, -) | F,B,H how, what-if, | truth values—T/F; 
why CF range-no limit 


RBH [ (Reis) 
CFOwI0) [| 


truth values—T/F ? 


yes 


automatic menus; line; | limited 
multiple responses 

line, CRSV, any language 
user-defined graphics 


automatic menus; line; 
active images; 
multiple responses; 
simulation; 
user-defined graphics 


Lisp 


automatic menus; line; 
multiple responses; 
user-defined graphics 


yes 


automatic menus; 
multiple responses; 
user-defined graphics 


automatic menus; line; 
multiple responses 
automatic menus; line; 


multiple responses; 
user-defined graphics 


Lisp 


any language 


any language 
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